The present invention relates to the field of collaborative computing and, more particularly, to unifying heterogeneous directory service systems.
A directory service is a service of a software system that stores, organizes and provides access to information in a directory. Directory services can look-up a uniquely identified individual and information associated with the individual. Unique directory objects often include users, groups, communities, membership, etc. Increasingly, it is desirable to make directory service information maintained in an enterprise system available to computing systems and applications outside the enterprise. This is especially true with many different types of collaboration applications, business to business applications, and social networking applications. Social networking applications, for example, often rely on directory services to provide account information. This practice contributes to a myriad of aspects of the social networking application—from the security to defining peer groupings and social network relationships.
Few integration problems result when a collaboration application (e.g., LOTUS CONNECTIONS) interfaces with a homogenous directory service system. This is especially true when the homogeneous directory service infrastructure based upon a single, popular standard, such as implementing enterprise-wide Lightweight Directory Access Protocol (LDAP) directory services. Unfortunately, enterprises do not necessarily maintain directory services as a homogenous manner. For instance, multiple different LDAP services can be employed to handle user accounts and groupings for corporate applications among different geographical locations, countries, and cultures with different languages. In many corporate infrastructures, different functional or geographic units of the corporation have local control and responsibility for maintaining information technology (IT) resources, which naturally results in non-uniform handling of IT resources including non-uniform handling of directory services.
Further, there is a growing demand from business partners to have machine-to-machine access to portions of an enterprise's computing environment to conduct business-to-business (B2B), business-to-consumer (B2C), and other e-business transactions. Directory services of an enterprise generally do not maintain unified records in their directory service system for business partners (B2B) and/or consumers (B2C) even though this information can be highly relevant to a collaboration application that relies upon directory service obtained information. It is expected that collaboration applications that depend upon directory service information (i.e., to determine unique users, groups, community memberships, etc.) will increasingly have to operate in environments that maintains needed information in a heterogeneous set of directory service systems.
Historical attempts to handle problems associated with heterogeneous directory service systems have been directed to consolidating information maintained by the heterogeneous set of systems into a single “master” directory management system. Often, a consolidation approach fails or requires significant situation unique work-arounds to be implemented, which are costly to establish, test, and maintain. That is, it is often not possible, by nature of directory services, to perform a straight forward consolidation of heterogeneous systems.
To elaborate, collaboration applications typically access directory services via Application Programming Interfaces (APIs). The core of this type of access requires identifying unique directory objects (e.g., users/groups) which can be structured in a manner specific to a particular directory service system. Typically, a canonical format for an object ID present in a directory service system is used to access directory objects. This canonical format can vary from system-to-system in a heterogeneous environment. Further, although all records of a discrete directory service system may be unique (as required), this uniqueness can fail when combined with data of other systems. Attempts to adjust data from different systems when forming a consolidated “master” directory service system, can cause original object identifiers to change. Thus, a canonical format valid in a homogeneous realm can be unrecognized in the federated realm, due to enforced uniqueness constraints, use non-canonical encoded IDs (e.g., proprietary/custom ID schema) within discrete ones of the directory service systems, and other such problems.